Tag Info

New answers tagged

0

Maybe adding env DISPLAY=:0 to the Upstart job would help? I think XBMC needs to be able to know what display to use, you know?


0

I'll take a shot, since no one else has offered an answer. Try changing your start condition to start on started tty1 My understanding of init systems is that they will happily start programs at weird times if you ask them to. Asking to start at the run levels could mean at the beginning of those run levels, before anything else has started. Like before ...


0

Instead of using Upstart, you can try to place your script snippet into /etc/X11/session.d/. Make sure that it is by the name of 99local and that it does not have a #!bin/sh header. It also should not be executable. This will ensure that your script is run after the xsession is set up and that it always runs, since the scripts in that directory are always ...


1

You are mixing up system and session jobs and events. lightdm emits the event just fine, but to the system instance of Upstart. Copy your ~/.config/upstart/touchpad.conf to /etc/init/ and change the start on event to login-session-start.


0

I have continued to beat on this and have it working, though it is not pretty. I put in a if-pre-up.d script, and took OUT the eth0 device from /etc/interfaces (which is the device I want to configure). Then when this fires (which may be multiple times), I manually configure eth0 with ip command lines (e.g. ip addr, ip route, etc.). I also write the ...


0

For the provided example: $ initctl status bluepill bluepill start/running, process 990 a quick solution for me is: # If upstart gets stuck for some job in stop/killed state export PID=990 cd /usr/local/bin wget https://raw.github.com/ion1/workaround-upstart-snafu/master/workaround-upstart-snafu chmod +x workaround-upstart-snafu ...


2

I believe I have an answer to my own question that leverages CameronNemo's partial solution and Mark Russell's answer to a related but somewhat different question. Two Upstart configuration files are required. The first is a job that starts as soon as the local filesystem is available, performs the desired file modifications as a pre-start script, and then ...


2

You can define a simple task job that start on event of your choice, run your script and at the end emit event to start the other two job. For example: # mainJob - # # This service emit myEvent to run firstJob description "emit myEvent to run firstJob" start on runlevel [2345] task console log script echo "(startTask) $UPSTART_JOB -- ...


0

Check firewall status and disable it $ sudo ufw disable Firewall stopped and disabled on system startup then restart xinetd service. $ sudo /etc/init.d/xinetd restart * Stopping internet superserver xinetd [ OK ] * Starting internet superserver xinetd [ OK ]


1

start on starting jobA or starting jobB instance $JOB pre-start exec /path/to/script The starting bit prevents the jobs from moving on in their life cycle until this job completes. The instance bit is so that both starting events (for jobA and jobB) are inhibited, not just one, as would be the case if you did not have an instance stanza. THe use of ...


0

The problem is that script sections in upstart are run with the set -e flag. This means the shell with exit if any command errors (like pgrep). THe solution is to add a || true after the pgrep command.


0

I had the same problem in my Ubuntu 14.04 Docker containers. As it turns out, the Ubuntu 14.04 image (if not others) for Docker does not support Upstart in the same way that a full virtual machine would. To answer this question, why the service does not start, it is because initctl is not an actual Upstart program: it is mapped to /bin/true. To verify run ...


0

Upstart job should look like this: chdir /home/application/bin exec /home/application/bin/startup.sh Of course, the necessary start on and stop on sections need to be added, and a description is advisable. Consult the Upstart cookbook for guidance there. (http://upstart.ubuntu.com/cookbook/)


2

Upstart has two types of jobs, session and system. system jobs only react to system events, but session jobs can react to session events or system events (when using the :sys: prefix). desktop-lock and desktop-unlock are session events. You need to place your upstart job into ~/.config/upstart/ for it to work correctly. Please note that it will therefore be ...



Top 50 recent answers are included