Re: [systemd-devel] networkd with radv advertised prefixes
Dne 09. 07. 2014 17:06, piše Tom Gundersen: On Wed, Jul 9, 2014 at 4:19 PM, Vasiliy Tolstov wrote: As i see, networkd now able to do dhcpv6, what about configuring interfaces to accept radv messages and configure it interfaces? What i need to do on systemd-networkd side? Currently that is not supported, but it is definitely something we want. So if you are interested in extending our libraries to cover this usecase, that would be awesome. I don't want to inject noise in signal of your conversation, but doesnt kernel itself do client side of ipv6 router solicitation/advertisement ? As I understood it, whole point of ra is to be so simple so that it doesn't need any special SW component on the client side and to be able to initialize automatically within interface activation. Branko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd with radv advertised prefixes
2014-07-09 21:06 GMT+04:00 Tom Gundersen : > Currently that is not supported, but it is definitely something we > want. So if you are interested in extending our libraries to cover > this usecase, that would be awesome. > > Cheers, I'm not fully understand what needed in networkd part. As i understand when interface is up linux kernel receives advertised prefix and all thing works automatically. Or you mean catch router advertised prefixes in userspace? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [sisyphus] Проблемы: systemd & display manager & LSB^ starting job ... networking
Oh, sorry. Wrong recipient. Ignore please. 9 июля 2014 г., 21:03 пользователь Alexey Shabalin написал: >>> > $ /sbin/sd_booted; echo $? >>> > 0 >>> > >>> > $ cat /etc/sysconfig/grub2 |grep systemd >>> > GRUB_CMDLINE_LINUX_DEFAULT='panic=30 splash vga=795 init=/sbin/systemd' >>> >>> если установлен пакет systemd-sysvinit, то init= не нужен. >> Он не установлен, потому что страшно безвозвратно с sysv уходить, с такими >> то знаниями в новом ините. >> >> Так как диагностировать почему сеть ругаеться при загрузке? > > без пакета systemd-sysvinit, с init=/sbin/systemd - это "на попробовать". > иначе у вас "неправильные" telinit, runlevel, shutdown, halt, poweroff, > reboot. -- Alexey Shabalin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd with radv advertised prefixes
On Wed, Jul 9, 2014 at 4:19 PM, Vasiliy Tolstov wrote: > As i see, networkd now able to do dhcpv6, what about configuring > interfaces to accept radv messages and configure it interfaces? What i > need to do on systemd-networkd side? Currently that is not supported, but it is definitely something we want. So if you are interested in extending our libraries to cover this usecase, that would be awesome. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [sisyphus] Проблемы: systemd & display manager & LSB^ starting job ... networking
>> > $ /sbin/sd_booted; echo $? >> > 0 >> > >> > $ cat /etc/sysconfig/grub2 |grep systemd >> > GRUB_CMDLINE_LINUX_DEFAULT='panic=30 splash vga=795 init=/sbin/systemd' >> >> если установлен пакет systemd-sysvinit, то init= не нужен. > Он не установлен, потому что страшно безвозвратно с sysv уходить, с такими > то знаниями в новом ините. > > Так как диагностировать почему сеть ругаеться при загрузке? без пакета systemd-sysvinit, с init=/sbin/systemd - это "на попробовать". иначе у вас "неправильные" telinit, runlevel, shutdown, halt, poweroff, reboot. -- Alexey Shabalin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: make ExecStopPost action part of ExecStart
On Tue, 08.07.14 18:01, Michal Sekletar (msekl...@redhat.com) wrote: > Currently after exiting rescue shell we isolate default target. User > might want to isolate to some other target than default one. However > issuing systemctl isolate command to desired target would bring system > to default target as a consequence of running ExecStopPost action. > > Having common ancestor for rescue shell and possible followup systemctl > default command should fix this. If user exits rescue shell we will > proceed with isolating default target, otherwise, on manual isolate, > parent shell process is terminated and we don't isolate default target, > but target chosen by user. > > Suggested-by: Michal Schmidt > --- > units/emergency.service.in | 3 +-- > units/rescue.service.m4.in | 3 +-- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/units/emergency.service.in b/units/emergency.service.in > index 94c090f..91fc1bb 100644 > --- a/units/emergency.service.in > +++ b/units/emergency.service.in > @@ -17,8 +17,7 @@ Environment=HOME=/root > WorkingDirectory=/root > ExecStartPre=-/bin/plymouth quit > ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, > type "journalctl -xb" to view\\nsystem logs, "systemctl reboot" to reboot, > "systemctl default" to try again\\nto boot into default mode.' > -ExecStart=-/sbin/sulogin > -ExecStopPost=@SYSTEMCTL@ --fail --no-block default > +ExecStart=-/bin/sh -c "/sbin/sulogin; @SYSTEMCTL@ --fail --no-block default" > Type=idle > StandardInput=tty-force > StandardOutput=inherit > diff --git a/units/rescue.service.m4.in b/units/rescue.service.m4.in > index 552ef89..ef54369 100644 > --- a/units/rescue.service.m4.in > +++ b/units/rescue.service.m4.in > @@ -18,8 +18,7 @@ Environment=HOME=/root > WorkingDirectory=/root > ExecStartPre=-/bin/plymouth quit > ExecStartPre=-/bin/echo -e 'Welcome to rescue mode! Type "systemctl default" > or ^D to enter default mode.\\nType "journalctl -xb" to view system logs. > Type "systemctl reboot" to reboot.' > -ExecStart=-/sbin/sulogin > -ExecStopPost=-@SYSTEMCTL@ --fail --no-block default > +ExecStart=-/bin/sh -c "/sbin/sulogin; @SYSTEMCTL@ --fail --no-block default" > Type=idle > StandardInput=tty-force > StandardOutput=inherit Patch looks good I figure, should probably go in, but I must say I really don't like the use of shell here, this is something we should be able to do with built-in functionality. I figure what we probably should do is allow passing multiple ExecStart= for all Type= settings. We currently only allow that for Type=oneshot, but we could open this up for all others too. Anyway, go ahead, commit this for now, but I think we should get this fixed properly within the service state machine. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: make ExecStopPost action part of ExecStart
If there are no further objections I will push the patch as is. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] networkd with radv advertised prefixes
As i see, networkd now able to do dhcpv6, what about configuring interfaces to accept radv messages and configure it interfaces? What i need to do on systemd-networkd side? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hostnamed: update documentation with new "watch" chassis type
On Wed, Jul 09, 2014 at 01:37:50PM +0200, Tomasz Torcz wrote: > --- > man/hostnamectl.xml | 3 ++- > man/machine-info.xml | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On Tue, Jul 08, 2014 at 06:44:19PM -0700, Josh Triplett wrote:
> On Wed, Jul 09, 2014 at 01:16:04AM +, "Jóhann B. Guðmundsson" wrote:
> >
> > On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
> > >On Tue, Jul 08, 2014 at 10:45:11PM +, "Jóhann B. Guðmundsson" wrote:
> > >>>
> > >>>On 07/08/2014 10:45 PM, Josh Triplett wrote:
> > >[Responding to this version because the latest thread hasn't appeared
> > >in
> > >the mbox archives yet. The comments apply equally well to the latest
> > >version, "Add DEPLOYMENT to hostnamectl".]
> > >
> > >On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
> > > >>+static bool valid_environment(const char *environment) {
> > > >>+
> > > >>+assert(environment);
> > > >>+
> > > >>+return nulstr_contains(
> > > >>+"development\0"
> > > >>+"staging\0"
> > > >>+"production\0",
> > > >>+environment);
> > > >>+}
> > >Can we please*not* attempt to limit or "standardize" this particular
> > >set of machine roles? As already demonstrated in the previous thread,
> > >people have all sorts of staged deployment strategies. Furthermore,
> > >the concept of a machine role shouldn't be limited to service
> > >deployment
> > >strategies.
> > >
> > >>>
> > >>>Roles != the environment they run in.
> > >I'm not trying to bikeshed over the naming of the variable itself. I'm
> > >arguing that standardizing this particular bit of metadata won't work
> > >well when so many different deployment strategies exist. Thus, rather
> > >than having a fixed set of keywords, I'd propose simply saying "this
> > >contains keywords", and leaving the specific keywords up to the admin.
> > >If you attempt to standardize production/development/staging, you'll
> > >either end up with a model that only works for a small subset of
> > >deployments, or you'll end up adding twelve more keywords, at which
> > >point you might as well have just said "use whatever keyword you like".
> >
> > The 4 tier covers the majority of the models since more or less the entire
> > internet recommend three tier model including M$ [1]
> > Anyone wanting to extend that further can do so using the "PRETTY_HOSTNAME="
>
> "PRETTY_HOSTNAME" does not equate to "description", and in any case is
> not the same thing as a deployment environment.
>
> > This patch is very specific to deployment environment and to solve a very
> > specific long standing problem and to achieve that we need to a standardize,
> > if we dont we can just as well drop this patch since in the long run we
> > cannot introduce something like "ConditionDeployment=" like David mentioned
> > and it kinda defeat's my purpose working in this in the firsplace...
>
> Distribution unit files will never use ConditionDeployment; only
> admin-created or admin-modified unit files will. Given that, it will
> work perfectly without a standardized set of names. Just specify that
> DEPLOYMENT contains a keyword *such as* (but not limited to)
> "production" or "development", and then state that ConditionDeployment
> can specify a keyword. That will work perfectly without limiting the
> set of possible keywords.
+1
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hostnamed: update documentation with new "watch" chassis type
--- man/hostnamectl.xml | 3 ++- man/machine-info.xml | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml index 7729ef6..eac3040 100644 --- a/man/hostnamectl.xml +++ b/man/hostnamectl.xml @@ -210,7 +210,8 @@ laptop, server, tablet, -handset, as well as + handset, + watch, as well as the special chassis types vm and container for diff --git a/man/machine-info.xml b/man/machine-info.xml index 7448e68..244e9b6 100644 --- a/man/machine-info.xml +++ b/man/machine-info.xml @@ -138,7 +138,8 @@ laptop, server, tablet, -handset, as well as + handset, + watch, as well as the special chassis types vm and container for -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
]] Lennart Poettering > On Wed, 09.07.14 12:58, Tollef Fog Heen (tfh...@err.no) wrote: > > > ]] "Jóhann B. Guðmundsson" > > > > > On 07/09/2014 08:33 AM, Tollef Fog Heen wrote: > > > > ]] "Jóhann B. Guðmundsson" > > > > > > > >> If we manage to do that, introduce "rolefulfilment=" in units which we > > > >> would define those standardized predefined set of roles as in for > > > >> httpd.service we might have rolefulfilment=web server, for postgresql, > > > >> rolefulfilment=database server etc. so you could list/query etc the > > > >> machine primary role and at the same time list the daemon/service who > > > >> fulfills that role > > > > It's not useful to know that a machine is a database server. It's > > > > useful to know if it's a postgres server or a mysql server or an oracle > > > > server, be it for monitoring or for connecting to it. > > > > > > Yes it is and if you dont see the benefits of knowing the roles of > > > your machine or containers and using roles in your infrastructure I > > > cannot help you. > > > > I know and use roles in my infrastructure, so that's not my question. > > I'm objecting to the use of a predefined list of roles, since that will > > not match my infrastructure, and I'm wondering what the use case for a > > very restricted list like that is. > > I think it would be wise to neither try to enforce normalization for the > "deployment" field, nor for the "role" field. I think the most commonly > used subset of the vocabulary should be documented in machine-info(5), > in all clarity, but if setups have different workflows or a different > scheme of assigning roles then that's totally fine. Sure, having a list of suggested roles is fine. > This is quite different from, let's say the chassis field, where we > actually do have a good idea of the various form factors systems are > built in, and where new form factors don't appear every day. I see the form factor «matchbox» is missing, though. (Think rPI/BBB cases). There's likely to be a ton more too, say, TV, microwave, stove, lightbulb, cable and so on, but I guess those can wait until people start building them. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
On 07/09/2014 10:58 AM, Tollef Fog Heen wrote: ]] "Jóhann B. Guðmundsson" On 07/09/2014 08:33 AM, Tollef Fog Heen wrote: ]] "Jóhann B. Guðmundsson" If we manage to do that, introduce "rolefulfilment=" in units which we would define those standardized predefined set of roles as in for httpd.service we might have rolefulfilment=web server, for postgresql, rolefulfilment=database server etc. so you could list/query etc the machine primary role and at the same time list the daemon/service who fulfills that role It's not useful to know that a machine is a database server. It's useful to know if it's a postgres server or a mysql server or an oracle server, be it for monitoring or for connecting to it. Yes it is and if you dont see the benefits of knowing the roles of your machine or containers and using roles in your infrastructure I cannot help you. I know and use roles in my infrastructure, so that's not my question. I'm objecting to the use of a predefined list of roles, since that will not match my infrastructure, Precisely it does not meet *your* particular needs. and I'm wondering what the use case for a very restricted list like that is. An list of strictly defined roles is needed for proper integration with wide variety of components and system policies ( think for example RBAC here ) etc. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
On Wed, 09.07.14 12:58, Tollef Fog Heen (tfh...@err.no) wrote: > ]] "Jóhann B. Guðmundsson" > > > On 07/09/2014 08:33 AM, Tollef Fog Heen wrote: > > > ]] "Jóhann B. Guðmundsson" > > > > > >> If we manage to do that, introduce "rolefulfilment=" in units which we > > >> would define those standardized predefined set of roles as in for > > >> httpd.service we might have rolefulfilment=web server, for postgresql, > > >> rolefulfilment=database server etc. so you could list/query etc the > > >> machine primary role and at the same time list the daemon/service who > > >> fulfills that role > > > It's not useful to know that a machine is a database server. It's > > > useful to know if it's a postgres server or a mysql server or an oracle > > > server, be it for monitoring or for connecting to it. > > > > Yes it is and if you dont see the benefits of knowing the roles of > > your machine or containers and using roles in your infrastructure I > > cannot help you. > > I know and use roles in my infrastructure, so that's not my question. > I'm objecting to the use of a predefined list of roles, since that will > not match my infrastructure, and I'm wondering what the use case for a > very restricted list like that is. I think it would be wise to neither try to enforce normalization for the "deployment" field, nor for the "role" field. I think the most commonly used subset of the vocabulary should be documented in machine-info(5), in all clarity, but if setups have different workflows or a different scheme of assigning roles then that's totally fine. This is quite different from, let's say the chassis field, where we actually do have a good idea of the various form factors systems are built in, and where new form factors don't appear every day. I'd also recommend not making the vocabulary to standardize on too large. Let's pick the 10 most common roles to document, but I am not sure I think it is worth trying to declare a specific name for any possible server there is in the world. systemd isn't really the place to standardize workflows or computing infrastructure setups with. We should cover the common cases well, and make the more exotic cases possible, and I think this is best done by documenting a digestable number of recommendations, and leaving the rest for users and admins to define. If you want to standardize more than that I figure this should happen outside of system, and we can add references to that to the man page. We do that all the time where we don't want to be the normative group. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
]] "Jóhann B. Guðmundsson" > On 07/09/2014 08:33 AM, Tollef Fog Heen wrote: > > ]] "Jóhann B. Guðmundsson" > > > >> If we manage to do that, introduce "rolefulfilment=" in units which we > >> would define those standardized predefined set of roles as in for > >> httpd.service we might have rolefulfilment=web server, for postgresql, > >> rolefulfilment=database server etc. so you could list/query etc the > >> machine primary role and at the same time list the daemon/service who > >> fulfills that role > > It's not useful to know that a machine is a database server. It's > > useful to know if it's a postgres server or a mysql server or an oracle > > server, be it for monitoring or for connecting to it. > > Yes it is and if you dont see the benefits of knowing the roles of > your machine or containers and using roles in your infrastructure I > cannot help you. I know and use roles in my infrastructure, so that's not my question. I'm objecting to the use of a predefined list of roles, since that will not match my infrastructure, and I'm wondering what the use case for a very restricted list like that is. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readahead: add option to create pack in directory other than root
On Wed, Jul 9, 2014 at 1:07 AM, Colin Walters wrote: > On Tue, Jul 8, 2014, at 05:12 AM, Lennart Poettering wrote: >> >> b) readahead-collect would check if /var/lib/systemd is on the same >>mount point as /. If so, it would store the file in >>/var/lib/systemd/readahead. Otherwise it would store the file in >>/.readahead, as before. > > If this logic was extended so that systemd also checked whether / was > writable, and fell back to writing to /var regardless, it would work for > OSTree at least. (/ is immutable on ostree since > https://bugzilla.gnome.org/show_bug.cgi?id=728006 ) Honestly, we should just remove all of readahead from the systemd tree. It is a blast from the past, does nothing but slow things down on modern machines. It should not be enabled by default, and stuff which we do not enable, can as well be provided by optional external packages instead of being maintained here. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
On 07/09/2014 08:33 AM, Tollef Fog Heen wrote: ]] "Jóhann B. Guðmundsson" If we manage to do that, introduce "rolefulfilment=" in units which we would define those standardized predefined set of roles as in for httpd.service we might have rolefulfilment=web server, for postgresql, rolefulfilment=database server etc. so you could list/query etc the machine primary role and at the same time list the daemon/service who fulfills that role It's not useful to know that a machine is a database server. It's useful to know if it's a postgres server or a mysql server or an oracle server, be it for monitoring or for connecting to it. Yes it is and if you dont see the benefits of knowing the roles of your machine or containers and using roles in your infrastructure I cannot help you. Making statement like this just because they might not be useful to your usecase scenario or workflow is simply silly. My best advice to you if this would get implement is simply dont use roles. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
]] "Jóhann B. Guðmundsson" > If we manage to do that, introduce "rolefulfilment=" in units which we > would define those standardized predefined set of roles as in for > httpd.service we might have rolefulfilment=web server, for postgresql, > rolefulfilment=database server etc. so you could list/query etc the > machine primary role and at the same time list the daemon/service who > fulfills that role It's not useful to know that a machine is a database server. It's useful to know if it's a postgres server or a mysql server or an oracle server, be it for monitoring or for connecting to it. > As well as all the other running service role fulfilment on the host > and maybe introduce ConditionRoleFulfilment= or ConditionRole= if > valid use cases existed for that etc. > > That's basically how I pictured the role implementation and from my > point of view if we cant standardized on predefined set of roles there > is no point in implementing it since we cant properly integrate roles > with units Maybe I missed the start of the conversation, but what's the problem you're trying to solve with this? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Seeking advice for configuring SystemCallFilter=
2014-07-09 2:33 GMT+02:00 David Timothy Strauss : > Is there a good way to empirically determine the additional calls > required for an application, sort of like selinux permissive mode? > We're often running user code on our servers, and we'd like to perform > analysis and gradually roll out filtering. We'd like to be as > non-disruptive as possible. Hi, Maybe you can use something like a syscall reporter [1] to tell you which syscall is needed ? But it means that you have to run the application, i'm not sure that's what you want. [1] http://outflux.net/teach-seccomp/step-3/syscall-reporter.c ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd service start/stop conditions
On Tue, Jul 8, 2014 at 1:00 PM, Mario Schuknecht wrote: > I have the following problem: > There are 3 (or more) systemd targets. Each of the three targets starts a > number of systemd services. > It can be switched back and forth between the systemd targets. > > As a limitation, it is necessary that the services of a target start only if > the services of actual target are already stopped. Because there have > resources to be released, such as a serial port. > > The problem is solved with Unit paramter Conflicts. Starting a target will > stop the other. When you isolate a target, stop jobs are async. Your system could complete isolation to a new target and still execute stop jobs from previous target. At least this was the case around systemd 200 ish. You might want to double check this with your "Conflicts" way if it is same there. Otherwise, it will not be %100 bullet proof for you. > > The following systemd units demonstrate the problem. > 3 systemd targets, 3 services and a dummy-program > > mode-1.target > > [Unit] > Description=mode 1 > > Conflicts=mode-2.target > Conflicts=mode-3.target > > [Install] > WantedBy=multi-user.target > > mode-2.target > > [Unit] > Description=mode 2 > > Conflicts=mode-1.target > Conflicts=mode-3.target > > After=mode-1.target > > [Install] > WantedBy=multi-user.target > > mode-3.target > > [Unit] > Description=mode 3 > > Conflicts=mode-1.target > Conflicts=mode-2.target > > After=mode-1.target > After=mode-2.target > > [Install] > WantedBy=multi-user.target > > unit-a-resource-1.service > --- > [Unit] > Description=Unit A use resource 1 > > After=mode-1.target > > Conflicts=mode-2.target > Conflicts=mode-3.target > > [Service] > ExecStart=/usr/bin/dummy_unit.sh "Unit A use resource 1" > TimeoutSec=10 > > [Install] > WantedBy=mode-1.target > > unit-b-resource-1.service > --- > [Unit] > Description=Unit B use resource 1 > > After=mode-2.target > > Conflicts=mode-1.target > Conflicts=mode-3.target > > [Service] > ExecStart=/usr/bin/dummy_unit.sh "Unit B use resource 1" > > > [Install] > WantedBy=mode-2.target > > unit-c-resource-2.service > > [Unit] > Description=Unit C use resource 2 > > After=mode-3.target > > Conflicts=mode-1.target > Conflicts=mode-2.target > > [Service] > ExecStart=/usr/bin/dummy_unit.sh "Unit C use resource 2" > > > [Install] > WantedBy=mode-3.target > > dummy_unit.sh > -- > #!/bin/bash > > running=true > trap 'echo got signal TERMinated; running=false' TERM > > echo "$1" > > # do something > while $running > do > sleep 1 > done > > # simulate longer shutdown > sleep 1 > sleep 1 > sleep 1 > sleep 1 > sleep 1 > > echo "$1 done" > > # > > Switch from mode-2.target to mode-1.target > systemctl start mode-1.target > > systemd[1]: Stopping Unit B use resource 1... > dummy_unit.sh[3303]: Terminated > dummy_unit.sh[3303]: got signal TERMinated > dummy_unit.sh[3303]: Terminated > systemd[1]: Stopped Unit B use resource 1. > dummy_unit.sh[3303]: Unit B use resource 1 done > systemd[1]: Stopping mode 2. > systemd[1]: Stopped target mode 2. > systemd[1]: Starting mode 1. > systemd[1]: Reached target mode 1. > systemd[1]: Starting Unit A use resource 1... > systemd[1]: Started Unit A use resource 1. > dummy_unit.sh[3322]: Unit A use resource 1 > > systemd service service unit-b-resource-1.service is stopped an than service > unit-a-resource-1.service starts. > > This all works only if the line > > After=mode-1.target > > exist in mode-2.target and the lines > > After=mode-1.target > After=mode-2.target > > exists in mode-3.target. > === > Without these lines, it looks like this: > > Switch from mode-2.target to mode-1.target > systemctl start mode-1.target > > systemd[1]: Stopping Unit B use resource 1... > dummy_unit.sh[1009]: Terminated > dummy_unit.sh[1009]: got signal TERMinated > systemd[1]: Starting mode 1. > systemd[1]: Reached target mode 1. > systemd[1]: Starting Unit A use resource 1... > dummy_unit.sh[1009]: Terminated > systemd[1]: Started Unit A use resource 1. > dummy_unit.sh[2873]: Unit A use resource 1 > dummy_unit.sh[1009]: Unit B use resource 1 done > systemd[1]: Stopped Unit B use resource 1. > systemd[1]: Stopping mode 2. > systemd[1]: Stopped target mode 2. > > systemd service unit-a-resource-1.service starts before the other service > unit-b-resource-1.service is stopped. > > Can anyone explain this behavior? (The parameter "After=" in mode-2.target > and mode-3.target but not in mode-1.target) > Can someone give a hint
