[opensuse] Re: [opensuse-factory] equivalent to boot.local for systemd
Andreas Jaeger wrote:
boot.local's use suggests it might be executed at most any point in the boot process, and after.local's used to be executed after the run level was reached. You can create separate service for these, there shouldn't be a
So far putting these into boot.local works fine, but my reading of problem...
So, what is the proper replacement for things that must be started after the system is up & running? On my firewall, I use after.local to start a 6in4 tunnel after booting, as it requires the network to be up first. There are other things that I have used after.local for, to ensure something started in a stable system. Does the crontab @reboot still work? If it does, it'd still require a delay, before executing the command. It would be nice if that systemctl had something guaranteed to run last. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/11 00:33, James Knott wrote:
Andreas Jaeger wrote:
boot.local's use suggests it might be executed at most any point in the boot process, and after.local's used to be executed after the run level was reached. You can create separate service for these, there shouldn't be a
So far putting these into boot.local works fine, but my reading of problem...
So, what is the proper replacement for things that must be started after the system is up & running? On my firewall, I use after.local to start a 6in4 tunnel after booting, as it requires the network to be up first.
[Unit] Description=My 6to4 tunnel After=network.target [Service] Type=oneshot ExecStart=/path/to/script/starting_the_tunnel.sh [Install] WantedBy=multi-user.target Aint that cute ? ;-)
There are other things that I have used after.local for, to ensure something started in a stable system.
we want to know what things are needed and the system is not doing properly by default.
Does the crontab @reboot still work?
Yeah, but it follows cron daemon bootup order. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/6/2011 7:42 PM, Cristian Rodríguez wrote:
On 07/12/11 00:33, James Knott wrote:
Andreas Jaeger wrote:
boot.local's use suggests it might be executed at most any point in the boot process, and after.local's used to be executed after the run level was reached. You can create separate service for these, there shouldn't be a
So far putting these into boot.local works fine, but my reading of problem...
So, what is the proper replacement for things that must be started after the system is up & running? On my firewall, I use after.local to start a 6in4 tunnel after booting, as it requires the network to be up first.
[Unit] Description=My 6to4 tunnel After=network.target
[Service] Type=oneshot ExecStart=/path/to/script/starting_the_tunnel.sh
[Install] WantedBy=multi-user.target
Aint that cute ? ;-)
Yes, but where does it go? after.local? -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/11 00:47, John Andersen wrote:
On 12/6/2011 7:42 PM, Cristian Rodríguez wrote:
On 07/12/11 00:33, James Knott wrote:
Andreas Jaeger wrote:
boot.local's use suggests it might be executed at most any point in the boot process, and after.local's used to be executed after the run level was reached. You can create separate service for these, there shouldn't be a
So far putting these into boot.local works fine, but my reading of problem...
So, what is the proper replacement for things that must be started after the system is up& running? On my firewall, I use after.local to start a 6in4 tunnel after booting, as it requires the network to be up first.
[Unit] Description=My 6to4 tunnel After=network.target
[Service] Type=oneshot ExecStart=/path/to/script/starting_the_tunnel.sh
[Install] WantedBy=multi-user.target
Aint that cute ? ;-)
Yes, but where does it go?
after.local?
After.local hack is still supported by editing /etc/init.d/after.local ... if you want to use the script I suggest above create it in a file named my6to4tunnel.service in directory /etc/systemd/system , issue systemctl --system daemon-reload then start the service with systemctl start my6to4tunnel.service, if you want it at boot time, issue systemctl enable my6to4tunnel.service -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
[Unit] Description=My 6to4 tunnel After=network.target
[Service] Type=oneshot ExecStart=/path/to/script/starting_the_tunnel.sh
[Install] WantedBy=multi-user.target
Aint that cute ? ;-)
Yep. All that to replace one whole line in after.local. Why not still have that after.local function included in systemctl? It is a very useful function. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/11 00:49, James Knott wrote:
Yep. All that to replace one whole line in after.local. Why not still have that after.local function included in systemctl? It is a very useful function.
After.local already starts after the network .. http://cgit.freedesktop.org/systemd/commit/?id=91b684c7300879a8d2006038f7d91... that will show up either in a future update or in the next opensuse version, I guess that solves your particular usecase of a 6to4 tunnel. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
Yep. All that to replace one whole line in after.local. Why not still have that after.local function included in systemctl? It is a very useful function.
After.local already starts after the network ..
http://cgit.freedesktop.org/systemd/commit/?id=91b684c7300879a8d2006038f7d91...
that will show up either in a future update or in the next opensuse version, I guess that solves your particular usecase of a 6to4 tunnel.
So, how does one get that into the current version? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/11 01:07, James Knott wrote:
Cristian Rodríguez wrote:
Yep. All that to replace one whole line in after.local. Why not still have that after.local function included in systemctl? It is a very useful function.
After.local already starts after the network ..
http://cgit.freedesktop.org/systemd/commit/?id=91b684c7300879a8d2006038f7d91...
that will show up either in a future update or in the next opensuse version, I guess that solves your particular usecase of a 6to4 tunnel.
So, how does one get that into the current version?
for this particular case, you dont have to :) Create a file named rc-local.service in /etc/systemd/system that says: .include /lib/systemd/system/rc-local.service [Unit] After=network.target and issue systemctl --system daemon-reload that's all for now, in later versions you can remove the custom unit or just leave it as is. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
Create a file named rc-local.service in /etc/systemd/system that says:
.include /lib/systemd/system/rc-local.service [Unit] After=network.target
and issue systemctl --system daemon-reload
I have tried that and it does not run after.local. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/11 12:36, James Knott wrote:
Cristian Rodríguez wrote:
Create a file named rc-local.service in /etc/systemd/system that says:
.include /lib/systemd/system/rc-local.service [Unit] After=network.target
and issue systemctl --system daemon-reload
I have tried that and it does not run after.local.
It will run if the service is enabled. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
and issue systemctl --system daemon-reload
I have tried that and it does not run after.local.
It will run if the service is enabled.
Is that not the purpose of the that issue systemsctl line? I ran that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/11 13:10, James Knott wrote:
Cristian Rodríguez wrote:
and issue systemctl --system daemon-reload
I have tried that and it does not run after.local.
It will run if the service is enabled.
Is that not the purpose of the that issue systemsctl line? I ran that.
systemctl --system daemon-reload --> reloads the actual configuration (hopefully will go away in the future when units are able to be reloaded atomically) systemctl is-enabled rc-local.service --> will tell you if it is actually enabled to start at boot. /var/log/messages will tell you why the unit failed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
systemctl is-enabled rc-local.service --> will tell you if it is actually enabled to start at boot.
The response says "static", whatever that means in this context. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/11 17:51, James Knott wrote:
Cristian Rodríguez wrote:
systemctl is-enabled rc-local.service --> will tell you if it is actually enabled to start at boot.
The response says "static", whatever that means in this context.
right, it is static , it will only be executed once during boot. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/11 18:34, James Knott wrote:
Cristian Rodríguez wrote:
right, it is static , it will only be executed once during boot.
Except it wasn't. This is a script that worked on 11.0 to start fetchmail.
See the logs to see what happended... hard to tell from here... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/6/2011 10:49 PM, James Knott wrote:
Cristian Rodríguez wrote:
[Unit] Description=My 6to4 tunnel After=network.target
[Service] Type=oneshot ExecStart=/path/to/script/starting_the_tunnel.sh
[Install] WantedBy=multi-user.target
Aint that cute ? ;-)
Yep. All that to replace one whole line in after.local. Why not still have that after.local function included in systemctl? It is a very useful function.
A meaningless function outside of the narrowest of contexts. Simple often isn't. It's simple and useful in the way that a single button is simple if the single button just luckily happens to do the one thing you want. But if you want to do something such as adjust the volume somewhere in between maximum or off, then that simple button is infinitely complex to the point that the desired action is not possible at all. systemd authors would say the concept of last doesn't even really make any sense. The last thing to run is init when it issues reboot() or halt(). Everything else is somewhere after one thing and before another thing, so just figure out what your action really needs, and what else really needs IT, and devise the appropriate set of conditions for systemd to either provide, or wait for. It's kind of too bad that you had no volume problem because you happen to keep the radio in the cellar so it was naturally a reasonable volume audible from everywhere else in the house, and so the introduction of this volume knob is such an unwelcome and unnecessary new complexity in your life, but really the single on/off button is not enough control to express the various things everyone else needs to do. Yes it's more complicated to reproduce certain actions that used to be simple, in trade, it makes other actions that used to be impossible, possible and even relatively simple. The difference between possible and not-possible outweighs the difference between possible in one line vs possible in one file. In fact, even the 10 line file is simpler than the one line in boot.after because a seperate file is infinitely more portable and manageable and automatable, _reliably_, than editing lines in existing files or files that may or may not exist. You are using Linux. It's far more complicated than Windows or OSX to do some of the same tasks. You are using a computer. It's far more complicated than pens and books and gramophones for certain tasks. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/8/2011 1:58 PM, Brian K. White wrote:
Yes it's more complicated to reproduce certain actions that used to be simple, in trade, it makes other actions that used to be impossible, possible and even relatively simple.
There never were actions that were impossible. There was always a way. It might have taken a bit of hacking but it could always be done, and hacking was seldom if ever actually necessary with sysv. It did 99.44% of things automatically the right way. What systemd seems to do is to turn that upside down, making everything complex so that the very few difficult things seem easy, even when those difficult things were rarely ever done. Volume control analogy = Fail. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/12/11 19:04, John Andersen wrote:
making everything complex
Things were already a complex mess of hacks and workarounds needed to fight the inevitable rotting of archaic software.
so that the very few difficult things seem easy.
which is exactly what we need, helps using our development resources, with are finite the most efficient way possible. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez said the following on 12/08/2011 05:44 PM:
Things were already a complex mess of hacks and workarounds needed to fight the inevitable rotting of archaic software.
The login of what's in, for example, /etc/rc3.d/ where the files names S are for when it starts that run level and the K files are for when you leave that run level are a kludge. The numbers are a kludge. The idea that you linearly "do this then that then that then that" is ludicrous. The idea of SystemD that there is an target-objective and dependencies makes me think of MAKE(1). Some of the dependencies _may_ have already been met and their ordering matters, though some can be done in parallel. The flexibility and generality of SystemD better reflects system management that the simple run-levels. It frees you from the idea of a hierarchy of states/levels and focuses on what facilities you want. Looking at it as a collection of files so misses the point. Looking at it as "something.after" so misses the point. In this case you are back to the linear sequence thinking instead of the target-objective thinking. I'm not saying that you couldn't construct a linear set of dependencies, but SystemD is capable of much more that that, more subtle and finer control. -- Each success only buys an admission ticket to a more difficult problem. -- Henry Kissinger, Wilson Library Bulletin, March 1979 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/8/2011 3:11 PM, Anton Aylward wrote:
The idea that you linearly "do this then that then that then that" is ludicrous.
No, its not. SystemD simply repackages that concept. You still do things linearly or at best a couple things in tandem. You can't avoid this and in the same paragraph talk about Dependencies. Its totally illogical. It makes no point to start Samba prior to having a network for instance. You want your cake and you want to eat it too. When it works for everyone I'm sure SystemD will be fine. But kludge as you seem to think it was, and old (translation: proven) as you claim it was, Sysv hasn't been the source of this many problem on this and other lists for many many years. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen said the following on 12/08/2011 06:53 PM:
Sysv hasn't been the source of this many problem on this and other lists for many many years.
Because sys init was a mature and proven concept by the time Linux cam along. You ddn't see its early birth pangs. It came out of the Unix Systems Group back in the beginning of the 1980s, proven and tested when System V came out. I recall getting my first copy of System V back in '82 when I was working for a shop that ported UNIX to various platforms[1] (including 16-bit microprocessors) and was delighted by how it cleared up the random, haphazard mess of scripts and code we had been using. Lists like this weren't around. USENET was around but this was before the Great Renaming. [1] And yes, I worked there with Richard Miller after he returned to Canada from Australia. -- The fact is that my native land is a prey to barbarism, that in it men's only God is their belly, that they live only for the present, and that the richer a man is the holier he is held to be. Saint Jerome, Letter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/8/2011 5:04 PM, John Andersen wrote:
On 12/8/2011 1:58 PM, Brian K. White wrote:
Yes it's more complicated to reproduce certain actions that used to be simple, in trade, it makes other actions that used to be impossible, possible and even relatively simple.
There never were actions that were impossible. There was always a way.
As someone who has had to write start scripts that handle situations that were never imagined when the basic scheme sysv init was imagined.
It might have taken a bit of hacking but it could always be done, and hacking was seldom if ever actually necessary with sysv. It did 99.44% of things automatically the right way.
What systemd seems to do is to turn that upside down, making everything complex so that the very few difficult things seem easy, even when those difficult things were rarely ever done.
sysv init is like DOS. It "worked fine" "for years and years". And in fact it did. But eventually the world channged beyond the point of such a simple system to remain useful. People just plain needed to use more than one program at a time and TSR's were'nt enough and even multi-user dr-dos/novell (hey we're on topic by two vectors!) wasn't enough. Although sysv init is almost infinitely flexible by the simple virtue of being mostly made out of shell scripts that you can write anything you want in to, there still are various basic assumptions that are no longer always true and they do get in the way and they will only get worse not better nor even stay the same. sysv init is a simple concept that is because of that very simplicity not able to handle the kinds of situations that exist today and tomorrow. At some point, the net payoff in backwards compatibility from torturing the old system is less than the net payoff in functionality usability from abandoning the old system.
Volume control analogy = Fail.
I disagree. Don't get me wrong. I don't think systemd is quite ready to be shoving down everyone's throats just yet either. I particularly think opensuse is in a crap state right now with the systemd integration being half-baked, documentation being wrong or incomplete, backwards compatibility shims being incomplete or non existant, making ?? how many years? of google results all broken overnight and breaking countless already written software over night, much of it old no-longer supported but still used and necessary commercial software, all broken, and with the new forced-march release schedule and short support life, the option to just use an older version that won't break everything will go away in mere months. But these are all suse distribution and implementation problems not really systemd problems. I just find all the arguments I've heard against systemd as a concept kind of stupid so far. People who don't happen to perceive a problem are just assuming that this actually means there IS no problem. How nice it must be to be so sure about everything by pure inference and assumption. http://25.media.tumblr.com/tumblr_lu3s15NBmF1qm4zvuo1_400.jpg -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 12/08/2011 06:30 PM:
Although sysv init is almost infinitely flexible by the simple virtue of being mostly made out of shell scripts that you can write anything you want in to, there still are various basic assumptions that are no longer always true and they do get in the way and they will only get worse not better nor even stay the same. sysv init is a simple concept that is because of that very simplicity not able to handle the kinds of situations that exist today and tomorrow.
Hey! Lets not forget that somewhere around UNIX System V time The Unix Systems Group introduced this sysv init stuff as al alternative to impractical mess of scripts that been grafted on to Version 7 and System III to make them support networking. Those were shell scripts too and we can see the path they went down to another 'alternative" in the various BSD and BSD-like packages. It's sort of like an elastic band. The concepts stretch so far and then become difficult to do more with and need replacing with something else. Nothing dramatic about this concept; all our technologies have gone through this, most of them repeatedly. -- Processes don't do work, people do. - John Seely Brown -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 09 December 2011, Brian K. White wrote:
On 12/8/2011 5:04 PM, John Andersen wrote:
On 12/8/2011 1:58 PM, Brian K. White wrote:
Yes it's more complicated to reproduce certain actions that used to be simple, in trade, it makes other actions that used to be impossible, possible and even relatively simple.
There never were actions that were impossible. There was always a way.
As someone who has had to write start scripts that handle situations that were never imagined when the basic scheme sysv init was imagined.
It might have taken a bit of hacking but it could always be done, and hacking was seldom if ever actually necessary with sysv. It did 99.44% of things automatically the right way.
What systemd seems to do is to turn that upside down, making everything complex so that the very few difficult things seem easy, even when those difficult things were rarely ever done.
sysv init is like DOS. It "worked fine" "for years and years". And in fact it did. But eventually the world channged beyond the point of such a simple system to remain useful. People just plain needed to use more than one program at a time and TSR's were'nt enough and even multi-user dr-dos/novell (hey we're on topic by two vectors!) wasn't enough.
Although sysv init is almost infinitely flexible by the simple virtue of being mostly made out of shell scripts that you can write anything you want in to, there still are various basic assumptions that are no longer always true and they do get in the way and they will only get worse not better nor even stay the same. sysv init is a simple concept that is because of that very simplicity not able to handle the kinds of situations that exist today and tomorrow.
At some point, the net payoff in backwards compatibility from torturing the old system is less than the net payoff in functionality usability from abandoning the old system.
Volume control analogy = Fail.
I disagree.
Don't get me wrong. I don't think systemd is quite ready to be shoving down everyone's throats just yet either.
I particularly think opensuse is in a crap state right now with the systemd integration being half-baked, documentation being wrong or incomplete, backwards compatibility shims being incomplete or non existant, making ?? how many years? of google results all broken overnight and breaking countless already written software over night, much of it old no-longer supported but still used and necessary commercial software, all broken, and with the new forced-march release schedule and short support life, the option to just use an older version that won't break everything will go away in mere months. But these are all suse distribution and implementation problems not really systemd problems.
I just find all the arguments I've heard against systemd as a concept kind of stupid so far. People who don't happen to perceive a problem are just assuming that this actually means there IS no problem. How nice it must be to be so sure about everything by pure inference and assumption.
http://25.media.tumblr.com/tumblr_lu3s15NBmF1qm4zvuo1_400.jpg
Yes, but even if systemd is not crap itself there is no good reason for releasing openSUSE with systemd per default while it does not work beyond grandma's use cases. Back to topic, even if using boot.local might be not the best idea to solve things ... it was suse specific for at least 10 years. Such things can't be simply silently diabled without declaring it obsolete for some time. BTW instead of using boot.local one could try crontab(5)'s "@reboot". cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu 08 Dec 2011 at 22:40:54 (-0300 UTC) Rüdiger Meier wrote:
On Friday 09 December 2011, Brian K. White wrote:
On 12/8/2011 5:04 PM, John Andersen wrote:
On 12/8/2011 1:58 PM, Brian K. White wrote:
Yes it's more complicated to reproduce certain actions that used to be simple, in trade, it makes other actions that used to be impossible, possible and even relatively simple.
There never were actions that were impossible. There was always a way.
As someone who has had to write start scripts that handle situations that were never imagined when the basic scheme sysv init was imagined.
It might have taken a bit of hacking but it could always be done, and hacking was seldom if ever actually necessary with sysv. It did 99.44% of things automatically the right way.
What systemd seems to do is to turn that upside down, making everything complex so that the very few difficult things seem easy, even when those difficult things were rarely ever done.
sysv init is like DOS. It "worked fine" "for years and years". And in fact it did. But eventually the world channged beyond the point of such a simple system to remain useful. People just plain needed to use more than one program at a time and TSR's were'nt enough and even multi-user dr-dos/novell (hey we're on topic by two vectors!) wasn't enough.
Although sysv init is almost infinitely flexible by the simple virtue of being mostly made out of shell scripts that you can write anything you want in to, there still are various basic assumptions that are no longer always true and they do get in the way and they will only get worse not better nor even stay the same. sysv init is a simple concept that is because of that very simplicity not able to handle the kinds of situations that exist today and tomorrow.
At some point, the net payoff in backwards compatibility from torturing the old system is less than the net payoff in functionality usability from abandoning the old system.
Volume control analogy = Fail.
I disagree.
Don't get me wrong. I don't think systemd is quite ready to be shoving down everyone's throats just yet either.
I particularly think opensuse is in a crap state right now with the systemd integration being half-baked, documentation being wrong or incomplete, backwards compatibility shims being incomplete or non existant, making ?? how many years? of google results all broken overnight and breaking countless already written software over night, much of it old no-longer supported but still used and necessary commercial software, all broken, and with the new forced-march release schedule and short support life, the option to just use an older version that won't break everything will go away in mere months. But these are all suse distribution and implementation problems not really systemd problems.
I just find all the arguments I've heard against systemd as a concept kind of stupid so far. People who don't happen to perceive a problem are just assuming that this actually means there IS no problem. How nice it must be to be so sure about everything by pure inference and assumption.
http://25.media.tumblr.com/tumblr_lu3s15NBmF1qm4zvuo1_400.jpg
Yes, but even if systemd is not crap itself there is no good reason for releasing openSUSE with systemd per default while it does not work beyond grandma's use cases.
Back to topic, even if using boot.local might be not the best idea to solve things ... it was suse specific for at least 10 years. Such things can't be simply silently diabled without declaring it obsolete for some time.
BTW instead of using boot.local one could try crontab(5)'s "@reboot".
cu, Rudi
Hello, (Apologies to pull in the middle of the interesting conversation...) I have recently installed Opensuse 12.1 64bits on a new laptop Lenovo z470 core i5 and everything went smooth and easy at first attempt. System is booting well and fast both when using Systemd or SysV when I switch by F5. Now I perceive that (please correct if I'm wrong) despite I can switch between systemd and sysv, whole system holds systemd related files and configurations that are still affecting or better influencing overall system behaviour. In other terms: is it possible to uninstall and clean the environment of all systemd related stuff? Many Thanks. Cheers, -- Marco Calistri <amdturion> By protracting life, we do not deduct one jot from the duration of death. -- Titus Lucretius Carus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Dec 09, 2011 at 10:54:24AM -0200, Marco Calistri wrote: [ 8< ]
(Apologies to pull in the middle of the interesting conversation...)
No sorry as you hijacked a thread. :) Read for example http://lists.opensuse.org/opensuse/2011-12/msg00117.html with a reference to http://en.wikipedia.org/wiki/Netiquette about thead hijacking. [ 8< ]
In other terms: is it possible to uninstall and clean the environment of all systemd related stuff?
It's not possible by the package dependencies nor is it realy required. See http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.1 about how to switch from systemd to syvinit. Check for 'Problem: System is switched from sysvinit to systemd during upgrade.' Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 10/12/2011 17:39, Lars Müller ha scritto:
On Fri, Dec 09, 2011 at 10:54:24AM -0200, Marco Calistri wrote: [ 8< ]
(Apologies to pull in the middle of the interesting conversation...)
No sorry as you hijacked a thread. :)
Read for example http://lists.opensuse.org/opensuse/2011-12/msg00117.html with a reference to http://en.wikipedia.org/wiki/Netiquette about thead hijacking.
[ 8< ]
In other terms: is it possible to uninstall and clean the environment of all systemd related stuff?
It's not possible by the package dependencies nor is it realy required. See http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.1 about how to switch from systemd to syvinit. Check for 'Problem: System is switched from sysvinit to systemd during upgrade.'
Lars
Thank you and sorry for the hijack! - -- Marco Calistri (amdturion) opensuse 12.1 (Aspargus) - Kernel 3.1.0-1.2-desktop x86_64 Gnome 3.2.1 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7jzG0ACgkQi4zJuA3lyFcynACfaWHtUyFlGb96Px6QHisUvE94 fBYAn171R2I6tTVr0mi4BmOIFp6ZC9i0 =B4Rz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/12/11 09:54, Marco Calistri wrote:
In other terms: is it possible to uninstall and clean the environment of all systemd related stuff?
No, it is not possible. There are Requires(pre,preun,post,postun) in rpm packages (or at least there should be.. ;) ) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Il 10/12/2011 18:52, Cristian Rodríguez ha scritto:
On 09/12/11 09:54, Marco Calistri wrote:
In other terms: is it possible to uninstall and clean the environment of all systemd related stuff?
No, it is not possible. There are Requires(pre,preun,post,postun) in rpm packages (or at least there should be.. ;) )
Thanks! -- Marco Calistri (amdturion) opensuse 12.1 (Aspargus) - Kernel 3.1.0-1.2-desktop x86_64 Gnome 3.2.1 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/6/2011 10:49 PM, James Knott wrote:
Cristian Rodríguez wrote:
[Unit] Description=My 6to4 tunnel After=network.target
[Service] Type=oneshot ExecStart=/path/to/script/starting_the_tunnel.sh
[Install] WantedBy=multi-user.target
Aint that cute ? ;-)
Yep. All that to replace one whole line in after.local. Why not still have that after.local function included in systemctl? It is a very useful function.
I like it! There you have *much* more than a one line script. A shell script that does similar would * verify that the network is up * verify that this hasn't been run before * make sure that this is run before going into multi user mode And probably do some error handling along the way. Very definitely NOT a one-line shell script! -- When languishing for solutions, don't ask "Have I got the correct answer?" The correct question is "Have I got the correct question?" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
we want to know what things are needed and the system is not doing properly by default.
Why not have a convenient place to list the things that are to be started after rebooting and the system has stabilized. It could even be called something like "after.local". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anton Aylward -
Brian K. White -
Cristian Rodríguez -
James Knott -
John Andersen -
Lars Müller -
Marco Calistri -
Rüdiger Meier