4 added 30 characters in body
source | link

It sounds likeSo you seem to want these processes to keep running indefinitely, i.e. they are service daemonsprocesses - which have been started inside the nested chroot environment. This rather suggests that you are spawning a service daemonprocess from your shell, instead of from systemd.

As aIn general rule, this is bad and you really don'twill want this to happenavoid it.

CentOS 7 uses systemd, running as PID 1 and providing service managementmanaging system services. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a system service process, it is forked off from PID 1 to provide a clean environment (customized according to the relevant .service unit file). (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(To illustrate this further: it is technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start your web server because there's already another program listening on TCP port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

It sounds like you want these processes to keep running indefinitely, i.e. they are service daemons - which have been started inside the nested chroot environment. This rather suggests that you are spawning a service daemon from your shell, instead of from systemd.

As a general rule, you really don't want this to happen.

CentOS 7 uses systemd, running as PID 1 and providing service management. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a service process, it is forked off from PID 1 to provide a clean environment (customized according to the relevant .service unit file). (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(To illustrate this further: it is technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start your web server because there's already another program listening on TCP port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

So you seem to want these processes to keep running indefinitely, i.e. they are service processes - which have been started inside the nested chroot environment. This rather suggests that you are spawning a service process from your shell, instead of from systemd.

In general, this is bad and you will want to avoid it.

CentOS 7 uses systemd, running as PID 1 and managing system services. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a system service process, it is forked off from PID 1 to provide a clean environment (customized according to the relevant .service unit file). (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(To illustrate this further: it is technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start your web server because there's already another program listening on TCP port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

3 added 30 characters in body
source | link

It sounds like you want these processes to keep running indefinitely, i.e. they are service daemons - which have been started inside the nested chroot environment. This rather suggests that you are spawning a service daemon from your shell, instead of from systemd.

As a general rule, you really don't want this to happen.

CentOS 7 uses systemd, running as PID 1 and providing service management. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a service process, it is forked off from PID 1 to provide a clean environment, customized (customized according to the relevant .service unit file). (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(For example, it'sTo illustrate this further: it is technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start Apacheyour web server because there's already somethinganother program listening on TCP port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

It sounds like you want these processes to keep running indefinitely, i.e. they are service daemons - which have been started inside the nested chroot environment. This rather suggests that you are spawning a service daemon from your shell, instead of from systemd.

As a general rule, you really don't want this to happen.

CentOS 7 uses systemd, running as PID 1 and providing service management. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a service process, it is forked off from PID 1 to provide a clean environment, customized according to the relevant .service unit file. (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(For example, it's technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start Apache because there's already something listening on port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

It sounds like you want these processes to keep running indefinitely, i.e. they are service daemons - which have been started inside the nested chroot environment. This rather suggests that you are spawning a service daemon from your shell, instead of from systemd.

As a general rule, you really don't want this to happen.

CentOS 7 uses systemd, running as PID 1 and providing service management. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a service process, it is forked off from PID 1 to provide a clean environment (customized according to the relevant .service unit file). (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(To illustrate this further: it is technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start your web server because there's already another program listening on TCP port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

2 added 30 characters in body
source | link

Sorry, as far as I can tell this is a rather bad idea.

It sounds like you are starting long-runningwant these processes -to keep running indefinitely, i.e. they are service daemons - which have been started inside the nested chroot environment. This showsrather suggests that you are startingspawning a service daemon outsidefrom your shell, instead of systemdfrom systemd.

As a general rule, you really don't want this to happen.

CentOS 7 uses systemd, running as PID 1 and providing service management. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a service process, it is forked off from PID 1 to provide a clean environment, customized according to the relevant .service unit file. (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(For example, it's technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start Apache because there's already something listening on port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

Sorry, as far as I can tell this is a rather bad idea.

It sounds like you are starting long-running processes - service daemons - inside the nested chroot environment. This shows that you are starting a service daemon outside of systemd.

CentOS 7 uses systemd, running as PID 1 and providing service management. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a service process, it is forked off from PID 1 to provide a clean environment, customized according to the relevant .service unit file. (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(For example, it's technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start Apache because there's already something listening on port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

It sounds like you want these processes to keep running indefinitely, i.e. they are service daemons - which have been started inside the nested chroot environment. This rather suggests that you are spawning a service daemon from your shell, instead of from systemd.

As a general rule, you really don't want this to happen.

CentOS 7 uses systemd, running as PID 1 and providing service management. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a service process, it is forked off from PID 1 to provide a clean environment, customized according to the relevant .service unit file. (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(For example, it's technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start Apache because there's already something listening on port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.

1
source | link