Tag Info

Hot answers tagged

16

What immediately comes to mind is an underprivileged user being able to run things on boot as root, which is desirable to crackers that: Want to escalate privileges of other accounts Want to use your server to host a rogue service Want to start IRC/Spam bots if the server reboots Want to ping a mother ship to say "I'm up again" and perhaps download a new ...


10

A background-job (ie. started with &) still has it's stdin, stdout and stderr connected to the terminal it was started in. It may suddenly write (eg. error-messages) to the terminal ("disturbing" the job in the foreground) or pause waiting for input from the keyboard (you must first put it in the foreground). You may of course redirect stdout and ...


8

Nothing. Different Linux distributions, and the LSB, had different standards, so both are present on CentOS to make it easier to run software from different versions. One is just a symbolic link to the other. http://www.centos.org/docs/5/html/5.1/Installation_Guide/s2-boot-init-shutdown-init.html gives details on the boot process, but ultimately all the ...


8

In addition to the very good points made by Tim Post, I'd add that for a setup where multiple people need to be able to push changes onto a server, you should consider using some kind of configuration management system. If you e.g. use puppet, or chef, or cfengine, you can have the relevant users edit the files locally and then push the changes out with the ...


7

Look in your conf file /etc/php5/fpm/php-fpm.conf. There you will find options user and group.


6

If I tell my system to go to run level 3 does that mean that it first runs through run level 0, 1, 2, and then finally runs through run level 3? No, it does not. Runlevels are not consecutive in that manner. Case in point: runlevel 0 is usually the "shutdown" runlevel, which stops all services and eventually halts (and possibly powers off) the system. ...


6

Good question. The only reference I've found to those files is in man insserv: /etc/init.d/.depend.boot, /etc/init.d/.depend.start, /etc/init.d/.depend.stop The make(1) like dependency files produced by insserv for booting, starting, and stopping with the help of startpar(8). And in fact, running just plain insserv touches ...


5

(open)SUSE uses /etc/init.d/after.local for this purpose. Just add the commands you need to be executed into that file. Note that this works fine with SystemV init, but with systemd this would need AFAIK need to be solved differently.


5

/etc/init.d scripts are non-interactive, non-login, and they don't try to access an X session because they are system wide services.1 System services aren't associated with any particular logged in user,2 but an X session always belongs to a logged in user. If your application needs a GUI context to work, it shouldn't be a system service. You have not ...


4

When you switch runlevel, the only things executed are the scripts in /etc/rc.d/rc${NEW_LEVEL}.d/. This means that you are right: Every rc*.d directory needs to be able to handle all of the process/service changes when switching from another runlevel. So every rc directory contains a full set of scripts for reaching that runlevel. Say you're switching to ...


4

Debian probably configured/patched nginx for their package to put the pid file someplace specific that it doesn't do by default. When you replaced it via something compiled from source, it doesn't match the expectations of the service infrastructure. I'd look at what patches and configuration options were done by the debian folks and recompile your 1.4.x ...


4

I recommend creating an Upstart script. First you want to create the script itself: sudo nano /etc/init/ts-server.conf Copy and paste this skeleton and make any changes you need: # description "start and stop the TS server" console log # Log events to console exec start-stop-daemon --start --chdir /home/teamspeak/server/ --chuid teamspeak \ --exec ...


4

But init.d screws me over by changing into a screen resolution that my monitor/graphics card does not support. I have the feeling it is some VESA mode that is being changed. I don't think that's an init process. That's the kernel. It occurs during the boot messages, right? If you compile the kernel without framebuffer support, it should not happen. ...


4

I know modprobe can be used to load modules, but how does it decide which modules to load? When the kernel needs a feature that is not resident in the kernel, the kernel module daemon kmod1 execs modprobe to load the module in. modprobe is passed a string in one of two forms. A module name like softdog or ppp. A more generic identifier like ...


4

The directory, /etc/init.d/ contains system scripts that essentially start, stop, restart daemons (system services). It's the "System V Initialization" method (SysVinit), containing the init program (the first process that is run when the kernel has finished loading). But, Firefox is a graphical Web browser. As such, it needs the window server (X-Windows) ...


4

init files, which run at system boot (or on demand) do two main things: they start daemons running they do various one-time-per-boot tasks, such as cleaning up or preparing files, setting network parameters, etc. In this case, the sudo init script does not start a daemon. Instead, it invalidates any cached credential files that may have been left around ...


4

The hyphen (-) found in an init script: #!/bin/sh # # chkconfig: - 24 73 means that the service should not be started in any run levels by default, only stopped. It replaces a list of run levels (e.g. 345) as shown below: #!/bin/sh # # chkconfig: 345 24 73 Therefore if you use: chkconfig --add <script> then no start links will be created in ...


3

I'm not sure where the /etc/init.d/skeleton file disappeared but I would expect that this change is related to replacement of traditional SysV init daemon with systemd since OpenSUSE 12. systemd is fully compatible with well knows initscripts but I would prefer to use the systemd model of starting services. In my opinion, traditional initscripts can be ...


3

Newer syntax for Suse Linux Enterprise 11 SP2 (and openSUSE ?) The best way would be to create a shell script that will call your PHP script. This shell script should have in its header the following comment: #!/bin/sh ### BEGIN INIT INFO # Provides: nothing # Required-Start: $all # Default-Start: 3 5 # Default-Stop: 4 # ...


3

What invoke-rc.d does is documented in its man page. It is a wrapper around running the init script directly, but it also applies a policy that may cause the command not to be run, based on the current runlevel and whether the daemon should be run in that runlevel. By default, Debian does not differentiate between runlevels 2-5, but as the local ...


3

If your application needs an X server for some weird reason but doesn't do anything useful with it, give it a virtual X server. This is commonly done to run web browsers in automated test suites for web applications — nobody's looking at the screen but the web browser won't run without one. Xvfb creates an X server that “displays” only to memory, not to ...


3

$HOME is an environment variable that is set on user login. Depending on how you login, the actual program that sets it can vary. If you login by console (including telnet/rlogin/etc), then it will be set by the login program. If you log in by SSH, it will be set by sshd. If you log in using a desktop manager, your desktop manager probably sets it for you. ...


3

You don't have to run abrtd, no. As per man abrtd: abrtd is a daemon that watches for application crashes. When a crash occurs, it collects the problem data (core file, application’s command line etc.) and takes action according to the type of application that crashed and according to the configuration in the abrt.conf config file. The default ...


3

As your init script shows, your delay is being caused by ntpdate when it starts. This is one of the most common errors when setting up NTP. The purpose of using ntpdate is so that ntpd won't exit with an error when it starts up. It does this if it detects that the time difference is very large. However ntpd has the ability to ignore this time difference ...


3

I don't know specifically about an init.d file, but a udev rule for running a script upon device-add might look like: ACTION=="add", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", RUN+="/path/to/executable" You should do some digging in udevadm to learn more about the way the device is typically added and its modules loaded. You'll also find the correct ...


2

This doesn't appear to be explicitly specified by the Debian policy, but Debian does support making /tmp a separate filesystem (as well as /home, /var and /usr). This is traditionally supported by unix systems. And I can confirm that making /tmp a tmpfs filesystem, and mounting it automatically via /etc/fstab, does work on Debian. There is some difficulty ...


2

To add a new init script is quite straight forward on Suse. The best way would be to create a shell script that will call your PHP script. This shell script should have in its header the following comment: #!/bin/sh #chkconfig: 35 99 00 #description: Notify of boot completion You can find a typical template (with loads of explanatory comments) in ...


2

You'll find the pre- and post- installation and removal scripts in /var/lib/dpkg/info. % ls -1 /var/lib/dpkg/info/hdparm.* /var/lib/dpkg/info/hdparm.conffiles /var/lib/dpkg/info/hdparm.list /var/lib/dpkg/info/hdparm.md5sums /var/lib/dpkg/info/hdparm.postinst /var/lib/dpkg/info/hdparm.postrm /var/lib/dpkg/info/hdparm.preinst hdparm.postinst (the script ...


2

To check which package a file belongs to, use dpkg -S: $ dpkg -S /etc/init.d/mountnfs.sh initscripts: /etc/init.d/mountnfs.sh mountnfs.sh belongs to an essential package called initscripts. Unless you wrote them, you should never remove scripts from /etc/init.d/. That is why the utility update-rc.d exists: to remove their symlinks from the /etc/rc*.d/ ...


2

/etc/init.d/rcS allows you to run additional programs at boot time. Its typical use is to mount additional filesystems (only the root filesystem is mounted at that point) and launch some daemons. Usually rcS is a shell script, which can easily be customized on the fly. Typical distributions make rcS a simple script that executes further scripts in ...



Only top voted, non community-wiki answers of a minimum length are eligible