JB <jb.1234abcd <at> gmail.com> writes: > > Michal Schmidt <mschmidt <at> redhat.com> writes: > > > ... > > > 2. > > > main-service-2.service: > > > [Unit] > > > Description=Main service 2 > > > After= ... > > > ... > > > [Service] > > > Type=forking<---------------------- any other type too ? > > > ExecStartPre= exec /etc/init.d/sub-service-1 > > > ExecStartPre= exec /etc/init.d/sub-service-2 > > > ExecStart= /usr/sbin/some-service > > > ExecStartPost= > > > ExecStartPost= > > > ... > > > Are there any restrictions on those Pre (and Post) commands ? > > > > One limitation was already mentioned somewhere in this thread - these > > commands must not fork off daemons. > > This is interesting. Or perhaps I read too much into your above statement ? > We know already that ExecStartPre must contain a command to be executed. > > > ExecStartPre= exec /etc/init.d/sub-service-1 > Note the 'exec' command, which means "Replace the shell with the given > command." with immediate return. > How does systemd know what's in the "/etc/init.d/sub-service-1" process, to be > able to figure out if any daemon is to be forked off ? > > > ... > > >> Parallelism in systemd happens between multiple units, but never between > > >> ExecStart* commands of one unit. > > >> Requesting parallelism within one unit seems like over-engineering to > > >> me. You can always split your unit to smaller ones if you want > > >> parallelism. > > > ... Regarding your statement on Parallelism. Let's consider these two ExecStartPre with 'exec': Is that still considered sequential execution, or parallel execution and a violation of the previous principle ? Actually, this question has a general ramification, as it applies to any of Pre, regular, and Post sequential execution principle within unit file. What is the meaning and purpose of "serial execution" within systemd ? - mechanical submit for execution, wait for return code, iterate - or more involved submit for execution, wait for command (job) completion, presumably to avoid ... parallelism and its potential side effects like any conflicts, races, etc; with return code, iterate JB -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
