Tag Info

New answers tagged

0

In reference to old-style SysV init scripts, the startup script or the configuration file specifies the user to drop privileges to. The script itself is run as root, but will often contain a su - <user> or runas <user> command within it to drop privs to the specified user. I'm not familiar enough with upstart of StartUp style service definitions ...


3

The service command is part of the sysvinit-utils package. Install it with: apt-get install sysvinit-utils But most probably, it is already installed in /usr/sbin/service. If it's missing in your $PATH, add this line to your ~/.bashrc: PATH=$PATH:/usr/sbin


2

To start your service at the end, run this command update-rc.d homemadeserviceName defaults 99 This will add a link inside /etc/rc.d as, S99homemadeserviceName Upstart will start services in the order of their numeric suffix... S0, S1, S2... and finally S99 services.


2

You must also use the update-rc.d command. There is the remove option to remove it from the boot sequence. The script will remain in the init.d directory and you are still able to start and stop them with the service command.


1

Try service tightvncserver start (as root) in the running system, it may give you some hints. If not, your best option is using a serial console and logging its output. If that isn't possible, bootlogd may be able to help you out. If you get nothing, maybe you forgot to activate your init script. What's the output of the $ ls /etc/rc?.d/*tightvncserver ...


0

I think the problem is with your quotes on line 11 of /etc/default/hostapd: ”/etc/hostapd/hostapd.conf” Which should read: "/etc/hostapd/hostapd.conf" Your post actually helped me solve my problem, so thanks!


0

If you have control over the dependencies (i. e. they are your software), make them install a drop-in file for the unit file in question. That is, let's say you have foo.service which needs to depend on bar.service || baz.service. Then the bar package can install a file /usr/lib/systemd/system/foo.service.d/50-bar-baz.conf with these contents: [Unit] ...


0

As it's already been said, there is deliberately no support for complex logic in systemd. If there is any start-up logic to do (and it isn't part of the daemon itself), it is completely OK to write a small shell script and specify it in ExecStart=. There is one thing to consider, though. The shell script must not do any process management by itself. The ...


0

You are not going to like this, but it works: ExecStart=/bin/bash -c '\ if [ ! -r /var/spool/torque/server_priv/serverdb ]; then \ DAEMON_SERVER_OPTS="-t create $DAEMON_SERVER_OPTS"; \ fi; \ exec /usr/sbin/pbs_server -- $DAEMON_SERVER_OPT'


0

There's no such facility in systemd - because this sort of logic really belongs inside of daemon. However if you can't change the daemon in question you can workaround it by first creating simple unit which will check file existence and create corresponding environment variable and than add "EnvironmentFile=" to your unit. Also add dependency to make sure ...


-1

You can use the systemd path units for that.Your service file should have a corresponding path unit to check for the path/file exists or not. Example: service.path [Unit] Description:Service description [Path] PathExists=!/other/service/binary/path/or/some/other/file/from/that/package [Install] WantedBy=some-user.target This one will activate your ...


0

The *nix way of doing this would be to start the script without a terminal and send the output to a log file. For example: app_server/a.out > /var/log/app_server.log & You can then add it to the user crontab with @reboot. Once that works, the real *nix way to do it is to create a service, with some form of IPC if necessary.


1

It depends how the init detects the service is running (ie. with a file socket). If you run the process without this configuration, the init doesn't know of the actual state of the service.


0

You'll need a combination of commands, depending on your Ubuntu version. Before systemd became the init system (pre-15.04), the following would suffice: service --status-all # for sysv init scripts initctl list # for Upstart jobs Some services might be listed by both service and initctl, in which case the Upstart job would usually be the right ...


3

Since Ubuntu has recently switched over to systemd, some services will be listed by upstart. service --status-all and others, by systemd systemctl -l --type service --all or as root systemctl -r --type service --all However software still using the init system will likely be listed in /etc/init.d Looking through all of those will yield most ...



Top 50 recent answers are included