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 ...


9

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 ...


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. ...


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

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

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

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 ...


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. ...


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

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

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. ...


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 ...


2

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 ...


2

Assuming that the node.js init script runs before sshd or any other external access script (otherwise, you could just login in remotely, disable the script, and then reboot), the easiest thing to do is to take your SD card to another computer and mount it there, find the init script, and move it out of the init directory. Yes, it requires an external system, ...


2

(I'm not trying to be pedantic, I just don't know how much you know or don't know, so I'm basically braindumping here) First off, just be aware that Red Hat picks weird stuff to install and enable by default. For instance it's either RHEL5 or RHEL6 that will install avahi and enable it to start at boot. I think both versions install and enable cups for ...


2

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 ...


2

Ther eisn't really anything out of the box that I'm aware of with fetchmail but you could easily construct something yourself like so. If you had a start) section to your /etc/init.d/fetchmail service: start) # Start daemons. echo -n "Starting fetchmail: " update_boot_stage 'Starting email fetching service' ...


1

You could put a simple cron script together that would monitor to see if the vpnc process is still up. If not, then run it. #!/bin/bash if [ "$(pidof vpnc)" ]; then echo "restart" ..run vpnc here.. else echo "running" ..do nothing.. fi Once you've created this script, call it /etc/cron.d/vpnc_checker.bash and create a crontab entry for it, in ...


1

The text mode login prompts appear after the startup programs have completed, including the ones run from /etc/rc.local. That's the point of startup programs: to be executed at startup, before users log in. If you want to run a program when the system starts, and you want to allow users to log in before your program completes, you have two options. Many ...


1

The ttys are spawned from /etc/inittab. By default the lines that spawn them come after the lines that run the rc scripts. For example, in my (un-customized) inittab, I have: ... l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 ...


1

For buildroot all your scripts must be placed in $path_to_buildroot/output/target/etc/init.d before build image. In my case this directory contains rcS and few scripts named S[0-99]script_name. So you can create your own start\stop script. rcS: #!/bin/sh # Start all init scripts in /etc/init.d # executing them in numerical order. # for ...


1

At first you should copy your script in pool of scripts: /etc/init.d/ linux have a set of dircetory that contain a set of link to this pool, at various runlevels: /etc/rc0.d # for runlevel 0 for trun off system in all of dirstos /etc/rc1.d # runlevel 1, for single user in all distros /etc/rc2.d # runlevel 2 , default runlevel for debian-base dirstros ...



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